The three kinds of shells the system needs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There's no POSIX shell in minibase, or anything resembling one, and no plans
to implement it. This is because conventional POSIX shell is a wrong tool for
most cases it gets used in.

One of the most prominent issues with POSIX shell is easy to illustrate:

	foo="some text here"
	bar=`echo "$foo" | tr a-z A-Z`

There is no point in spawning a process (or two) just to do a simple string
substitution. Definitely not when we take shell size in account; pdksh is about
as large as lua, and bash is an order of magnitude larger. Somehow the shell
strives to be a proper language and at the same time fails badly at it.

Another issue is that traditionally the shell was meant to be used both as
an interactive application and as a scripting language. Interactivity costs
a lot in terms of code, dependencies, and design trade-offs. This is widely
realized, and several prominent distros now use something simpler than
a full-blown interactive shell to run their scripts.

So what should replace POSIX shell in minibase? I would argue that there
should be three separate applications (or three classes of applications)
handling the tasks traditionally relegated to the shell:

  1. dumb batch command runner
  2. proper scripting language
  3. interactive shell

The following is an attempt to justify this split, and chart the roadmap
for future implementation.


The dumb batch command runner
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lots of shell scripts (and shell use cases in general) do not involve any
flow control. No loops, often no conditions, just a list of commands to run.
A "language" that's just enough to run them can be made *really* small.

The batch runner should be able to parse argv[]s from a file and exec them.
Its primary goal is to lessen the pressure on the scripting language, making
it less likely to be used for trivial cases when things like startup time
become noticeable. Careful choice of built-ins can also extend its capability
pretty far, perhaps completely covering system startup for instance.

This thing is already in minibase, it's called `msh`.


The scripting language
~~~~~~~~~~~~~~~~~~~~~~
This language should take over any non-trivial shell scripts. That is, anything
with loops, conditions, or error recovery.

Since msh already took over the trivial scripts, this one won't be called for
no reason, so it does not need to be particularly small or particularly simple. 
It should be able to run external commands with ease, but it can be so with
something like system(), it does not need to look like shell.

One possible description for such a language could be: a much simpler Perl.
That's how Perl originated anyway. If so, it could probably take over sed,
awk, grep and most of minor tools like kill. Also any uses of ls, find, ps
for scripting. Anything dealing text files or pipes in traditional Unix way
could then be done completely within this language, and likely within a single
process.

# Note "much simplified" Perl means no CPAN and NO F*#$%&% MODULES.

Another option could be Lua, with built-ins necessary to make it into
a system scripting language. Stuff like process control, non-portable
file ops, easy access to common /etc formats and so on.


The interactive shell
~~~~~~~~~~~~~~~~~~~~~
This is the only one of them that needs to deal with keyboard input and
human-readable output on regular basis. The key point: it does not need
to look like anything resembling bash or POSIX shell at all!

That's because interactive shell is primarily a (mini-)IDE.
Its purpose is navigating file system, editing the code, running it,
and dealing with the output produced. Think a cross between mc, tmux
and kilo.

# Side note: the idea that interactive shell is in fact IDE is not really
# new, and not really obscure. But it's not always clearly stated.
# The features that set the new advanced shells like zsh or fish apart,
# like extended completition support or fancy prompts or git integration,
# those aren't feature of an interpreting language. Those are IDE features.

Whether or not this IDE should come with a built-in language is debatable,
and my opinion is that it shouldn't. Instead it should be a code editor
for the system scripting language(s) and/or msh.

Interactive shell should definitely spare the user from typing ls all the
time, or using find for that matter. Between this and the scripting language,
find and ls should probably disappear as standalone commands at some point.

# Check ./vtvstty.txt here for more info on interactive shells.


The recovery shell
~~~~~~~~~~~~~~~~~~
Finally there's an emergency tool that shouldn't really exist in a properly
set up system, but may be extremely useful in restricted settings. It's a
small conventional direct-exec shell with command line interface, currently
called `cmd`.

The point in having this tool is to allow the user to run simple commands
without relying on indirect exec service or ptys or whatever. 
Think initrd that drops the user into a shell if it cannot locate the root
paritition. Or a router that isn't supposed to be used interactively at all,
but needs to provide a serial or ssh shell. That's the use cases for the
recovery shell.

This thing is not supposed to be used as the primary user shell, ever,
only as a fallback. The reason it is used in minibase-br right now is the
lack of anything better.
